Disclaimer: I am aware that this is test code, and in this particular context speed does not matter much, but I'm making this point thinking about the use case that this change is designed to serve, i.e. adding annotations arbitrary modifications to all objects.

I'm concerned that this added round of deserialization/serialization will slow things down even more (compared to how slow helm-based operator already is).

Can you think of any other way that we could inject annotations to already-deserialized objects? Perhaps there is a different helm library hook that we could leverage? Or maybe we can ask for one?

One of the ways we could do this is using the controller-runtime interceptor, intercept the create/update calls, and handle structured and unstructured objects and lists to append the annotations before creating or updating the objects. Users could also implement a custom MutatingWebHook to add annotations. Or maybe even update the charts themselves ?

Though in stackrox's desired usecase (apply user-provided overlay patches), this could only be done, AFAIK, using de & reserialization.

Oh, right, it's for arbitrary modifications, not just annotations. I updated my comment above.

However given that this library already does a deserialize+reserialize in the ownerPostRenderer I think it might be better to refactor the code there to allow adding custom visitors that could walk already parsed objects, rather than custom postrenderers that would repeat the same work?

I'm not sure, because the user might want to remove parts of the manifest altogether, or add new resources to it, which would not be possible with a walk.
I ran some benchmark tests, and the impact seems negligible. Deserializing then re-serializing an object from-to a yaml manifest takes roughly 0.0003 sec. I ran a test with 1000 deployments in 1 manifest (extremely large manifest), and it takes 0.27 sec.

Good point about visitor not being powerful enough for some use cases!

However I still think this change would be exposing functionality at the wrong level of abstraction.
It looks like the PostRenderer hook exposed in the helm library works on the level of bytes.Buffer objects because this is a natural fit for exposing it from the helm CLI - since that works on the level of command pipelines.

While this works, and the overhead seems manageable (thanks for checking this!), I think it forces the API user to do unnecessary work, so is not elegant.

What do you think about exposing a kube.ResourceList instead? (That one has Append and Filter, for example).

Good point about visitor not being powerful enough for some use cases!

However I still think this change would be exposing functionality at the wrong level of abstraction.
It looks like the PostRenderer hook exposed in the helm library works on the level of bytes.Buffer objects because this is a natural fit for exposing it from the helm CLI - since that works on the level of command pipelines.

While this works, and the overhead seems manageable (thanks for checking this!), I think it forces the API user to do unnecessary work, so is not elegant.

What do you think about exposing a kube.ResourceList instead? (That one has Append and Filter, for example).